The invention relates to a ring network, and particularly to a system and an implementation technology for actualizing MAC (media access control) bridging on RPR (Resilient Packet Ring) protocol mainly defined by IEEE802.17.
The RPR is a network protocol technology mainly aiming at being provided a network for connecting between cities, such as MAN/WAN (Metropolitan Area Network/Wide Area Network). An examination of the RPR is underway in order to establish a draft at the IEEE802.17 Committee. As of September in 2002, Draft version 1.0 (tentative specifications) as first standard specifications were released, at which stage they were approved at the meeting at the end of September, and the final specifications are scheduled to be determined in March in 2003 through necessary modifications thereafter. The RPR is based on SRP (Spatial Reuse Protocol) released by Cisco Corp. and has the following features.    1. The RPR supports a bidirectional dual ring network.    2. The RPR supports a MAC layer in layer 2.    3. An effective utility rate of a using bandwidth is high.    4. The RPR supports Plug & Play.    5. A protection switching time is sub-50 ms.
Note that the SRP is described in, for instance, a Patent document 1.
The following points in addition to the above-mentioned are characteristic of the RPR.    1. There are three priority classes, and it is easy to implement QoS (Quality of Service) control on the high-order layer.    2. A protection switching system is a steering protection (which is a system for switching a route having a failure to another route of a reversed direction along the ring, and a wrapping protection (which is a system for turning the route having a failure back in the reversed direction along the ring just anterior to a failure point) is an option.    3. The RPR is a system that is limited to the MAC layer in the regulations and does not depend on the lowest-order layer (the physical layer).
The RPR is a novel MAC layer protocol and terminates the MAC frame. Accordingly, a basic idea has hitherto been such that a device (a RPR device) implementing the protocol should be a device (which is router, gateway, and the like) executing a layer process higher than this. At the recent IEEE meetings, however, an examination for defining a forwarding method so that the RPR device can function as a device (which is a so-called bridge) capable of transparently forwarding the MAC frame, is underway.
With respect to the forwarding method, a good deal of problems and methods for solutions thereof are presented, and finally a forwarding method based on IEEE802.1D was proposed. The proposed method also, however, has a problem, and, in the present, standards of the forwarding method are not yet taken shape.
For describing the technology according to the invention of the present application, the following terms will at first be defined.
(1) MAC frame: the “MAC frame” is a frame having a MAC header. Herein, this indicates a frame of the Ethernet (registered trademark) defined in IEEE802.3 and a frame having a RPR MAC header defined in IEEE802.17. Especially in the case of distinguishing therebetween, there are called an “EMAC frame” and a “RMAC frame”, respectively. FIG. 17 shows formats of the EMAC frame and the RMAC frame.
(2) Node: the “node” is a device for actualizing the RPR protocol. Each node exists on bidirectional dual rings (two counter-rotating ringlets). In the specification, the node might be called a “RPR node” and also called a “RPR device”.
(3) Station: the “station” is a device that terminates the MAC frame. The station receives the MAC frame and transfers a data field thereof to a high-order layer. Further, the station assembles the MAC frame including data from the high-order layer and transmits it. When the station receives the MAC frame, if the MAC frame has an error, or a destination MAC address (MAC DA) of the MAC frame is not coincident with a MAC address of the station itself, the MAC frame is basically discarded. In case a receipt frame is a RMAC frame, however, the RMAC frame is made to pass through on the side opposite to the side of having received it. In a case where a node (a RPR node) that performs processing of the RPR protocol has functions as the station, the node is called a “station node”.
(4) Bridge: the “bridge” is a device that forwards the MAC frame as far as any error does not occur. Normally, the bridge copies and distributes the MAC frame received at one of physical ports to all other physical ports. Further, the bridge has a MAC address learning function, and creates and keeps a table (called “a port-to-MAC address mapping table” or “MAC learn table”) from MAC DA/SA (source address) of MAC frames to be forwarded, The table shows a physical port to which a device indicated by the source/destination addresses of the MAC frame is connected. The bridge checks MAC DA/SA of each received MAC frame. If the MAC SA is not registered in the table, the bridge registers the MAC SA with an identifier of a physical port (e.g., port number) received the MAC frame to the table. Further, if the MAC DA is already registered in the table, the bridge forwards the MAC frame to only a physical port corresponding to the MAC DA by referring the table. An extra load is thereby prevented from being applied to other ports. In a case where the node (the RPR node) performing the processing of the RPR protocol has the bridge function, this node is called a “bridge node”.
Next, a method of transmitting and receiving the RMAC frame between the stations, which is tentatively defined in IEEE802.17, will be at first explained as a prior art (see, for instance, Non-Patent document 1).
FIG. 18 shows one example of a RPR network. FIG. 18 shows a plurality of nodes SA-SL as station nodes each having the station function. The nodes SA-SL are sequentially connected in a ring-shape in a state (sequence) illustrated in FIG. 18 via bidirectional communication lines (two counter-rotating ringlets). Normally, an optical fiber is used as communication line. Herein, for the sake of explanation, the RPR network is defined as follows.    <1> MAC addresses of the respective nodes are:SA: MSA, SB: MSB, . . . SL: MSL    <2> Clockwise connecting sequence (outer ringlet) is:SA→SB→SC . . . SL→SA    <3> Counterclockwise connecting sequence (inner) is:SA→SL→SK . . . SB→SA
In the RPR, it is defined that a node, when receives a MAC frame, performs processes as below.
(A) An error check is conducted based on FCS/HEC of the MAC frame, and, if there is an error, the MAC frame is discarded.
(B) In case there is no errors, the MAC DA of the MAC frame is checked, if the MAC DA is coincident with a MAC address of the node itself, the MAC frame is captured inside, and a data field thereof is transferred onto the high-order layer.
(C) When the MAC address is not the MAC address of the node itself, the MAC SA is checked. If the MAC SA is coincident with the node's MAC address, the MAC frame is discarded.
(D) In case it is not coincident, a value of TTL (Time to Live) of the MAC frame is checked. If the TTL value is under 1 (not TTL=1), the MAC frame is discarded.
(E) When the TTL value is 1 or more (TTL=1 is established), one (1) is subtracted from the present TTL value, and the MAC frame is reassembled (concretely, the HEC and FCS are recalculated) and transmitted to a next neighboring node (which is called “pass”).
Accordingly, the node SA shown in FIG. 18, in the case of transmitting a frame to the node SD, assembles a RMAC frame as shown in FIG. 19.
Normally, each node (the node SA) transmits the frame onto a ringlet of a direction (which is called “near (short) direction”) that the number of nodes forwarding the frame is small. Therefore, the node SA transmits the frame to the outer ringlet.
The frame reaches at first the node SB. The node SB, as the MAC DA of the frame is not coincident with the MAC address of the node SB itself, lets the frame pass through (to be concrete, transmits the frame to the neighboring node SC corresponding to the next node). At this time, one is subtracted from the TTL value of the frame. The node SC executes the same process as the node SB does, and the frame arrives at the node SD. The node SD, as the MAC DA of the frame is coincident with the MAC address of the node SD, captures the frame inside the node SD, and transfers the data field of the frame onto the high-order layer, thus completing the process.
For executing the process described above, each node is required to specifically grasp the number of forwarding nodes, each of which exists between a source node (node itself) and the destination node, with respect to each direction of ringlet (outer and inner ringlets). In the RPR protocol, for achieving the object, a control packet that is called a topology discovery packet for grasping a topology of the ring (each ringlet), is transferred and received between the RPR nodes. The topology discovery packet includes the MAC addresses, as pieces of information, of the source node itself and the neighboring nodes thereof. Each of the nodes receiving the topology discovery packet adds a piece of self-information (a MAC address of the node itself) and sends it to the neighboring node. These processes are executed each node. Eventually all the nodes are thereby able to know the MAC addresses of all other nodes and the number of the forwarding nodes (which is precisely a value of TTL needed for the frame transmission). Each node retains them as a topology map table. By way of an example, FIG. 20 (Table 1) shows the topology map table retained on the node SA illustrated in FIG. 18. Note that the topology discovery packet is, when in an initial setting in addition to when adding and deleting the nodes, periodically transmitted and received between the respective nodes, whereby updated information of the network can be kept at all times.
Further, in case of failures occurred in the node or on the communication line between the nodes, each node, when detects the failures, sends a control packet called a protection packet to all other nodes. Each of the nodes is thereby notified of a change of the topology. The change of the topology is immediately reflected in the topology map table. By way of an example, FIG. 21 (Table 2) shows a change of the topology map table when a failure occurred on the communication line for transmitting the frame the node SD from the node SC to the node SD illustrated in FIG. 18. Thus, a state of the topology is reflected in the topology map table. Thereby, it is indicated that the node SA cannot perform communications, about each node further than the node SD, by using the outer route. Therefore, the node SA can actually judge that using the inner route to perform communications to each node further than the node SD. Such a technology is called steering and is one of the principal technologies of the RPR.
Now, in the case of applying the RPR to a normal network, other than the nodes on the rings, a variety of networks such as the Ethernet, etc. are normally connected, and it is required that the communications between stations (off-the-ring stations), each of which is located in the outside of the rings and is accommodated to one of nodes (on-the-ring nodes) on the rings, be possible.
Originally, the RPR is based on an assumption that the frame is routed between the off-the-ring stations via the high-order layer. Namely, the MAC frame, which has been received by the node on the ring and comes from the off-the-ring station, is temporarily designated in its forwarding destination (other on-the-ring node) by the high-order layer and is then transmitted as a frame of a RPR MAC layer onto the ring. Then, the frame is received by a different node on the ring, then also designated in its forwarding destination (an off-the-ring station) by the high-order layer, and transmitted to a destination station after becoming a frame of an outside protocol. This forwarding procedure indicates that the node on the ring must invariably be a router. In the case of the same layer protocol as the RPR where the frame dealt with by the off-the-ring station is an Ethernet frame, etc., however, there is a large load in terms of a cost and a speed.
The IEEE802.17 Committee, for solving the above problem, assumes a MAC bridging system for giving a bridge function of forwarding the MAC frame with no intermediary of the high-order layer, and is going to incorporate a function of making the RPR node function as a bridge into the rules. At the present, a prospective rule on the occasion of actualizing the function may be a transparent bridge system, defined in IEEE802.1D, and the rules of IEEE802.17 will be settled in the direction (refer to, e.g., Non-Patent documents, 2, 3, 4, 5).
The transparent bridge system has, however, some problems that will be given as follows. The IEEE802.17 Committee also pointed out the problem, and, in the present situation, tangible standard rules of the bridge function are not yet seen.
A bridge device for executing MAC bridging, in the case of being installed as, for instance, a bridge node on the RPR network defined in IEEE802.17 as shown in FIG. 22, must be capable of the following communications (refer to, e.g., Non-Patent document 6).    1) SX-BJ-BD-SY communications (bidirectional)    2) SX-BJ-SA communications (bidirectional)    3) SA-SG communications (bidirectional, bridge pass)
For enabling all these communications, a transparent bridge system of IEEE802.1D was proposed at the IEEE802.17 Committee. In the case of applying the system directly to the node in the RPR network, the bridge node executes frame processing (a transparent translation) shown in FIG. 23.
In FIG. 23, the on-the-ring bridge node executing the framing processing learns information about which on-the-ring bridge a MAC address off the ring where the communications are performed is linked to, and sorts out it into a table. The communications 1) through 3) can be thereby performed. The transparent bridge system has, however, the following problems pointed out by the IEEE802.17 Committee (refer to, e.g., Non-Patent document 7).
A relationship between the MAC address of the bridge node and the MAC address of the off-the-ring device connected to the bridge node, remains unlearned. Therefore, in the bridge node through which the frame addressed to the off-the-ring device is passed, the frame is copied addressed to the network connected to the bridge nodes (which is called blooding), and there is a possibility of increasing the load on the network.
According to the RPR, normally in the case of transmitting the MAC frame from a certain node on the ring to a different unspecified node, in a ringlet selection, the smaller in TTL is to be selected. In a case where BJ-BD distances are equal in the network illustrated in FIG. 22, normally any one of the routes is predetermined. Herein, in the case of transmitting the frame on a route of SX→BJ→SA→BD→SY, the bridge nodes BL, BC existing in the middle of the route can learn from the passing frame that the station SX is connected to the bridge node BJ.
The bridge node, however, in the case of not yet learning that the station SY is connected to the bridge node BD, there being a possibility that station SY might be connected to the self-device (the bridge node itself), therefore copies the frame simultaneously when it passes through and transmits the frame to the off-the-ring network connected to the self-device. Moreover, the bridge nodes BF, BI through which the frame does not pass are unable to learn that the station SX is connected to the bridge node BJ.
Supposing that there is a response on the higher-layer than the station SY, the frame is transmitted to the station SX and transferred across a route of SY→BD→SG→BJ→SX (because if the respective stations take the same algorithm, the equal distance implies a selection of the same direction), in which case the bridge nodes BF, BI can learn that the station SY is connected to the bridge node BD. The bridge nodes BL, BC are, however, unable to learn. Further, the bridge nodes BF, BI do not yet learn that the station SX is connected to the bridge node BJ, and therefore send a copy of the frame to the network off the ring.
When the frame arrives finally at the station SX from the station SY, the communications between the stations SX-SY via the outer route (the above route) become possible. However, the intermediate bridge nodes BL, BC, BF and BI cannot ever learn the address of the frame passing through the nodes themselves, resulting in a constant occurrence of the blooding (see FIG. 24: for example, Non-Patent document 8, slides 11 and 12).
As a method of preventing the problem given above, there is a method of sending a response thereof in the frame-coming direction. For instance, the bridge node BJ starts transmitting round the outer ring to the station SY, and the bridge node BD also starts transmitting round the outer ring to the station SX. In the method, in a case where the respective stations SX, SY simultaneously transmit the frames to the destinations, the frames are passed round the outer ring and reach the destinations, while responses thereof are returned round via the inner ring to the destinations, and further responses thereof go round the outer ring and so on, resulting in an oscillating state where the destinations are floating. This induces a possibility in which the frame sequence might be reversed depending on a delay of frame transmission (refer to, e.g., Non-Patent document 8, slides 7 and 8).
Further, as shown in FIG. 22, the communications between the stations SZ-SY involve using in principle a shorter route. Accordingly, the bidirectional communications via a route of SZ-BL-SA-BD-SY, are performed. Herein, if the communication line to BL→SA is disconnected (cut off), the communications round the outer ring in a direction of SZ→SY cannot be carried out. Hence, the inner ring is used according to the steering. At this time, the respective bridge nodes BJ, BF, BI did not learn that the station SY is connected to the bridge BD. Accordingly, the flooding occurs. Besides, a response thereof is sent via a route of SY→BD→SA →BL→SZ round the inner ring as it used to be so far. This makes it impossible forever to learn f about the address mapping described just above (see FIG. 25: for instance, Non-Patent document 9, slides 11 and 12).
As a method of preventing the aforementioned problem, there is a method of transmitting the response in the frame-coming direction in the same way as in the first problem. If a longer route between the bridge nodes BD-BL is selected, however, there are a larger number of cross-over nodes than by selecting the shorter. Accordingly, more of the whole usable bands are used up as a result. In other words, the load on the network rises.
Thus, the transparent bridge system in the present situation has a possibility that an extra load increases in some cases.
<2> For the reason of a reliability, etc., the frame addressed to the device on the off-the-ring network connected to the plurality of bridge nodes has no information about where to go and might be lost.
As shown in FIG. 29, it is considered from a point of view of the reliability that the off-the-ting station SY is connected to the two bridge nodes BC, BD on the ring. At this time, the selection of the connection between the station SY and the bridge nodes BC, BD, is determined by applying Spanning Tree Protocol defined in IEEE802.1D. Supposing that a route between BC-SY is selected, for instance, the frame is transmitted and received between the SX-SY via the bridge node BC, and each of the on-the-ring nodes learns that the station SY is connected to the bridge node BC (FIG. 26: normal state).
Herein, if a failure occurs between BC-SY, the station SY selects a route between BD-SY in accordance with the Spanning Tree Protocol. The bridge node BC, however, simply judges that the communications with the station SY fall into a failure, and there is no method of knowing that the bridge node BD can surrogate. Hence, the frame sent addressed to the station SY is taken back by the bridge node BC, wherein the frame is judged to have the failure and discarded. Accordingly, all the frames from the station SX to the station SY do not reach in spite of an existence of the route of BD-SY (FIG. 27: failure state between BC-SY). This makes it meaningless to connect the station SY to both of the bridges BC and BD in order to enhance the reliability (refer to, e.g., Non-Patent document 8, slides 9 and 10).
As a plan for solving the problem, the IEEE802.17 Committee proposed that a flooding bit is provided in the RPR header. The processing is executed so that all the nodes on the ring can receive the frame in which the flooding bit is set irrespective of whatever destination it may have. FIG. 28 shows diagram of this concept. The plan enables the frame to reach the destination even in such a case as <2> by creating a method of flooding the frame to all the node at all times. Further, all of the node can always learn the same content. Accordingly, any problem as in <1> does not arise.
The use of the communication bands of almost all the nodes for a certain frame, however, conduces to a loss of Spatial Reuse (a reuse of a space) that is greatly characteristic of the RPR. As a matter of fact, the system based on the plan described above comes to have substantially the same operation as the frame is transmitted and received in a case where the bridge device on the Ethernet actualized at the present is connected onto the ring. Therefore, a problem occurs afresh, wherein the meaning of utilizing the RPR is lost.
These problems are derived from the RPR MAC header destination address becoming none of the addresses of the nodes on the ring because of transmitting the frame transparently. In other words, the on-the-ring node that should receive (should do forwarding) cannot be designated uniquely by the MAC address, which becomes a factor for causing the respective problems as described above by the transparent bridge system.
Such being the case, the IEEE802.17 Committee is examining a method of scheming to obviate the problems in such a form as to add an original EMAC address to the RMAC frame in the case of translating the EMAC frame into the RMAC frame. This is called an enhance bridge system. The following format plans are proposed for the system.
(Plan-A) A System for Transmitting and Receiving by Adding the MAC Address to the RPR Format
FIG. 29 shows a format plan in which the MAC address is added. This plan-A is a method of invariably adding an address, as a destination, of the on-the-ring node to the Ethernet frame coming from outside the ring by the on-the-ring node. The plan-A is capable of obviating the problems. In order to make the off-the-ring MAC address corresponding to the on-the-ring MAC address, a transparent bridge learns which bridge node on the ring the station off the ring is connected to and sorts out it into a table format (e.g., Non-Patent document 9, slide 17).
The plan-A has, however, the following defects. Namely, the plan-A has not compatibility with the RPR format used so far. Therefore, a device manufactured base don the plan-A is impossible of communicating with the existing device. This implies that an existing LSI for the RPR MAC layer processing that has been designed for the RPR device, cannot be used. Further, in the plan-A, al the nodes on the ring must execute the process (the process of adding the on-the-ring MAC address). Hence, in the communications between the station nodes on the ring, the same address must be set in the RPR MAC address and in the MAC address. This kind of process is futile as far as the communications between the on-the-ring station nodes are concerned. Moreover, the format related to the plan-A has such an aspect that the overhead is always large and data communication efficiency is poor.
(Plan-B) A Plan for Distinguishing by a Flag as to Whether the MAC Address is Added or not
An addition of the MAC address is originally a piece of information needed only for the case where the bridge is related to the communications. Accordingly, there is considered a plan for adding the MAC address only in such a case that one (or both) of the transmitting and receiving sides is the bridge node. This plan-B is shown in FIG. 30. A difference between the plan-A and the plan-B is given as follows. Namely, the plan-A is that the format is changed by adding the RPR MAC address at all times. By contrast, the plan-B is that the RPR MAC address is added only in a required case, and the communications are performed in the existing format other than this case. Accordingly, the addition of the RPR MAC address is not applied to the communications between the station nodes on the ring.
The on-the-ring bridge node and station node, however, must distinguish between the addition and non-addition of the MAC address, depending on the communication partner. Therefore, the information (flag: 1 bit at the minimum) for judging whether the MAC address is added to the RPR header or not, is needed.
The plan-B has the following defects. Namely, the format to which the flag is added as in the plan-B has no compatibility with the original format as in the plan-A. Further, the plan-B must involve adding the flag to the RPR header afresh. Hence, there is no compatibility with the device manufactured based on the existing specifications, and the existing RPR MAC layer LSI can not be used. The plan-B, however, unlike the plan-A, enables the communications with the existing device with respect to the communications between the station nodes. Moreover, in the plan-B, the RPR MAC address is not always added. Therefore, the overhead for a whole traffic is smaller than the plan-A.
(Plan-C) A Plan for Encapsulating the Whole Frame in the Bridge
For giving the compatibility to the format, there is considered a method of encapsulating the whole MAC frame (EMAC frame) with the RPR MAC frame in the bridge. A format related to the plan-C is shown in FIG. 31 (for example, Non-Patent document 9, slide 21, Non-Patent document 10, and slide 11).
The plan-C has a necessity of registering afresh ET (Ethernet Type) for indicating encapsulation (an application to IETF is required). It is not a problem to simply encapsulate the MAC frame in the plan-C. If this remains as it is, it follows that protocols (IEEE802.1Q-VLAN, MPLS, etc.) for adding a label to between the header and the payload can not be supported (IEEE802.17 has a rule enabling these protocols to be supported. For processing on these protocols, new ETs are also required to be registered, and the ETs just corresponding to the number of protocols for processing are needed.
In any plan among the plans A through C explained above, in the case where the transmitting destination is the off-the-ring station subordinate to the bridge, when a mapping between the MAC address of the station and the MAC address of the on-the-ring bridge node is learned, the transmission becomes possible by adding the MAC address corresponding to a transmitting source and a destination on the ring.
In the case of newly adding the station subordinate to the bridge, there is a case where a mapping relationship therebetween is not yet learned. In this case, it is required that the frame be sent to all the nodes (precisely to only the bridges therein). Hence, a broadcast MAC address is added as a destination MAC address. The frame (the RPR frame) to which the broadcast MAC address is added, is received by each of the nodes. The bridge node receiving the RPR frame translates the RPR frame into an Ethernet frame and thus sends it to all the subordinate ports off the ring. If there is a device 8a device having MACDA of the Ethernet frame) having the MAC address in any one of the off-the-ring ports, the device is capable of receiving a desired Ethernet frame. The station ruled out of the destination of the Ethernet frame receives the Ethernet frame, interprets its body frame and thereafter discards it.
For actualizing the processes described above, in any plan among the plans A through C, the new format (or the encapsulated format) to which the MAC address is added must be interpreted by the node (see FIG. 32). This implies that neither the plan-A nor the plan-B nor the plan C enables the device for processing only the existing format to be disposed within the ring (see FIG. 33).
For others, technologies described in the following Non-Patent documents 11 through 17 are given as the prior arts related to the invention of this application.    [Patent document 1] Specification of U.S. Pat. No. 6,314,110    [Non-Patent document 1] IEEE Draft P802.17/D1.0 (P802-17D1-ob.pdf), chapters 5, 6, 8 and 10, Internet    [Non-Patent document 2] Bridging Ad-Hoc (BAH) Overview (bah-upd-01.pdf), Internet, May 2002    [Non-Patent document 3] Bridging on 802.17 LAN with 802.1D/Q Compliance (bah-dot1-01.pdf), Internet, May 2002    [Non-Patent document 4] Basic Bridging Compliance (bah-basic-03.pdf), Internet, July 2002    [Non-Patent document 5] Enhanced Bridging Spatial Reuse of 802.17 Bridge Traffic (bah-enhnc-02.pdf), Internet, July 2002    [Non-Patent document 6] IEEE802.17 Frame Structure and Bridging Ad-Hoc Support (bah-frm-01.pdf), Slides 11, 17, 21, Internet, May 2002    [Non-Patent document 7] Flooding in 802.17 Networks (bah-fld-01.pdf), Internet, May 2002    [Non-Patent document 8] 802.1D/Q Compliance and Spatial Reuse (bah-spt-01.pdf), Slides 7-8, 9-10, 11-12, Internet, May 2002    [Non-Patent document 9] BAH 802.17 Frame Structure Requirements (bah-frame-02.pdf), Slide 11, Internet, June 2002    [Non-Patent document 10] BAH Summary (bah-motion), Internet, May 2002    [Non-Patent document 11] 802.17 presentations (bah-fld-01.pdf), Internet, July 2002    [Non-Patent document 12] Bridging Ad-Hoc (BAH) Overview (bah-over-01.pdf), Internet, July 2002    [Non-Patent document 13] 802.17 Bridging Compliance Roadmap (bah-road-01.pdf), Internet, July 2002    [Non-Patent document 14] TA Document IEEE802.17-11 July 2001/0.40:3, October 2001 (Basic-Bridging-Draft-Text.pdf), Internet, July 2002    [Non-Patent document 15] Proposed D0.3 Changes for Enhanced Bridging Jul. 1, 2002 RESILIENT PACKET RING (RPR) (bridge-spat-draft02.pdf), Internet, July 2002    [Non-Patent document 16] IEEE Draft P802.17/D0.3 Contribution, DRAFT STANDARD FOR (Flooding.pdf), Internet, July 2002    [Non-Patent document 17] IEEE Draft P802.17/D0.3 Contribution Jun. 28, 2002, RESILIENT PACKET RING (RPR) (Formats.pdf), Internet, July 2002